Replication of the simulation
#############################

The idea to simulate the trade flows of the German-speaking countries after the Congress of Vienna emerged around 2014, upon the realization that Postgres, a SQL-based database system that also had a GIS extension (PostGIS) available as well as a routing framework (pgrouting) was up to the task (relatively humanly readable SQL statements, almost guaranteed finalization of the code if maybe not as quick as it could have been achieved in a pure Java or C++ implementation). In order to replicate these simulations, you need your own Postgres server (we used version PostgreSQL 11.12 for the published results. You then install postGIS (published results were achieved with version 2.5, incl. GEOS and Project stat). Last, you need pgrouting (published results: Version 3.0.0, Release, 2020/07/14).

We optimized the Postgres server to take very few connections and allocate all of the RAM and CPU on these. The Java files in this replication package then run these simulations by querying the SQL server. It makes sense to have the Java client sit on the same physical machine as the SQL. Using Ubuntu's "screen" command, you can then have the whole thing run while you go on with your life- some simulation runs took a week.

The simulation relies on the maps of the German Empire from Kunz and river data (full references in the paper). After importing these to Postgres, create_waystable.sql creates a navigable network comprised of notes and edges. It prepares the river to be shipped, the sea to be sailed from harbour to harbour, and also includes the street network. Travelling costs are calculated using the rates from Sombart. You can already have some fun with navigating these maps then, using pgrouting (see their documentation). Our counterfactual analyses are created by making changes to the Kunz maps, and then run create_waystable.sql on these counterfactual maps.

The Java project, starting with ViennaSimulator.jar uses these data in a structured way. Its output is a couple of SQL tables with each a line for each round and state, incl. its tariff rate (optimal) and the resulting revenue. You can then use your favorite SQL client (we started with PgAdmin, but went over to Jupyter to the end of the project) to browse the results, and aggregate the data to the tables as published in the paper.

For example:

"SELECT revenue FROM case_little_optimal_random_1 WHERE period=1 ORDER BY state".

The aggregation of all runs and filtering on the 50th period is reported in the paper. As you can see yourself from the output of the program, there is much more data to be explored, i.e. how the tariffs are built up from a "blockade" situation, and states become more and more competitive about their rates.